PUNCTAJE OBTINUTE DE STUDENTII CARE PARTICIPA LA CURSUL Calitate software in 2013 - 2014
| |||
CAM CUM TREBUIAU SOLUTIONATE SUBIECTELES1:a)seturile de date trebuie specificate concret cu valori initiale si cu rezultate; trebuia un tabel cu cateva coloane unde aveai: SET-1, X, Y si A; dadeai valori lui X si Y si aratai cine trebuie sa fie A; mai adaugai si situatiile in care datele erau nenumerice si la A puneai un mesaj b) la curs v-am zis ca o formula se scrie grad de acoperire GA e dat de relatia: GA=NCA/NTC unde: NCA - numar cazur testate NTC - numar total cazuri c) calitatea procesului de testare e data de diversitatea seturilor de date, de gradul de acoperire, de detaliile oferite celor care se ocupa de depanare, de procedurile utilizate p[entru a identifica neconcordantele intre ceea ce trebuie sa faca programul si ceea ce face el in realitate. S2: a) trebuiau enumerate tipurile de interfete specificand inainte care este criteriul de clasificare utilizat; dupa aceea luai fiecare tip de interfata si-l descriai, aratand ce are specific, cui se adreseaza, care este structura, complexitatea si ce are in comun fiecare tip cu alte aplicatii b )enumerate caracteristicile (generalitate, continuitate, mentenabilitate, complexitate,portabilitate, reutilizabilitate si la fiecare ziceati o definitie si aratati cum proiectati o interfata sa indeplineasca aceste caracteristici c ) etapa de masurare a calitatii aplicatiei depinde de: durata de elaborare a aplicatiei, durata de testare, volumul procedurilor care se realizeaza simultan, metricile utilizate, modul de achizitie a datelor; in ipoteza achizitiei automate, a existentei unui software de calcul indicatori si a calculului la sfarsitul procesului de testare, ceea ce se cere in enunt este la nivelul catorva minute, sa zicem 10; voi luati alte ipoteze si obtineti alte durate; daca vreti construiti si modele in care apar durate pentru achizitii de date, durate pentru efectuarea calculelor indicatorilor; durate pentru analize comparate; durate pentru stabilirea cailor de crestere si durate pentru efectuarea modificarilor, cu reluarea testarii; daca introduceti factorul K al numarului de reluari a procesului de testare pana se obtin diferente acceptabile intre ceea ce s-a planificat si ceea ce s-a realizat, modelul vostru devine si mai interesant; daca imaginati un system de ponderi tinand seama de complexitatea aplicatiei si obtineti p1+p2+p3+ . . .+pn=1 unde pn este ponderea calculului calitatii, la o complexitate C a aplicatiei, durata de obtinere a valorilor pentru calitate in raport cu o metrica data DQ este data de relatia DQ=pn * C'fiind creativi aveati nenumarate moduri de a da raspuns la aceasta chestiune S3: a) Ion IVAN, Catalin BOJA, Cristian CIUREA - Metrici lae sistemelor colaborative, Editura ASE, Bucuresti, 2007, ISBN 978-973-594-963-1, 186pg. Aveati la dispozitie sa scrieti despre articole, despre conferinte; daca veti fi rigurosi, clar ca veti avea si argumentele de a va sustine ideile indicand clar si exact de unde provine ceea ce sustineti daca este o idee a altcuiva b)erorile despre care aveati posibilitatea sa discutati erau legate strict de etapa la care ati ajuns sa lucrati; daca erla definirea de problem erorile sunt: de stabilire a datelor de intrare (tipuri, enumerare lista, de unde se culeg, periodicitatea, domeniul, absenta unor tabele effective; luarea in considerare a unor date de intrare care privesc alte prelucrari decat cele stabilite ca obiectiv; preluarea de date redundante ascunse sub nume diferite; sunt greseli care se fac si care au costuri foarte mari daca se doreste indreptarea lor; prin lipsa de date de intrare, problema este subdefinita sau este neconsistenta caci se cer niste rezultate pentru care lipsesc datele de intrare. Tot asa procedati pentru oricare etapa din ciclul de realizare. Si la implementare se fac erori, dintre care cele mai frecvente sunt legate de echipamentele subdimensionate, de absenta unor medii de edzvoltare a aplicatiei, manipularea gresita care conduce la stergerea de fisiere sau distrugerea bazelor de adte (de test). Pentru erorile de codificare - ceea ce s-a cerut - lucrurile sunt si mai simple:definiti variabile si nu le initializati; formulele din specificatii difera de cele din secventele de program; scrieti o procedura de mai multe ori; proceduri diferite le comasati intr-o procedura foarte greoaie; incercati sa reutilizati ceva care este foarte diferit de ceea ce cere aplicatia. Ca programatori nu exista ca la 10 programe sa nu aveti cel putin 3-5 erori de acelasi tip. Daca spuneti si ce risipa de resurse s-a facut din aparitia acestor erori in mod repetat este si mai complete abordarea. Caci trebuie invatat din toate cate ceva. c) experienta arata ca documentatia se face pe fuga la sfarsit si de fapt trebuie facuta pe masura ce se parcurg etapele; specificatiile se elaboreaza pe masura ce se scrie programul; Solutia tehnica se da tinand seama de ceea ce exista in firma si nu este vorba de a elabora variante dintre care este aleasa aceea care se demonstraza ca este cea mai buna; comentariile in textul sursa lipsesc sau se scriu mult mai tarziu. Asamblarea componentelor nu nurmeaza o regula ci se face la final, fara testarea complete a componentelor, testare care trebuia sa se faca la predarea de component. Daca spuneti si cum faceti sa nu mai repetati aceste nerespectari este si mai bine. Daca aveti neclaritati, va rog sa mi le comunicati la adresa ionivan@ase.ro cu subiectul CS2013-LUCRARE gggg nume si prenume | |||
|
|
BIBLIOGRAFIA |
|
05 noiembrie 2013 |
GRUPA 1057 GRUPA 1058 GRUPA 1059 |
al II-lea IE
29 octombrie 2013 |
GRUPA 1057 GRUPA 1058 GRUPA 1059 |
al II-lea IE
15 octombrie 2013 |
GRUPA 1057 GRUPA 1058 GRUPA 1059 |
al II-lea IE
8 octombrie 2013 |
GRUPA 1057 GRUPA 1058 GRUPA 1059 |
al II-lea IE
Afisat azi 10 octombrie 2013.
